4. Pre-Creating Your Content Databases
If your organization has a SQL
DBA that manages all of your companies’ databases, including your
SharePoint databases, you have the option of asking your DBA to
pre-create your content databases from within SQL Server. You can then
point to these pre-created databases from SharePoint, SharePoint will
recognize them, and the databases will become part of the farm.
The advantage of pre-creating
databases is that all the Model database settings are inherited,
including the Autogrowth setting that is not inherited when you create
your content databases from within SharePoint. However, a disadvantage
is that the default collation setting of the Model database is
SQL_Latin1_General_CP1_CI_AS, which is not compatible with the required
SharePoint database collation type. Therefore,
your DBA will have to be sure that the pre-created content databases
use the appropriate database collation type of
Latin1_General_CI_AS_KS_WS, as shown in Figure 7.
Note:
BEST PRACTICE
During the installation of SQL Server that is dedicated to SharePoint,
you can choose the SharePoint-required collation of
Latin1_General_CI_AS_KS_WS. This will ensure it is used for all
databases created in this instance of SQL Server, regardless of whether
they are created from SharePoint or SQL Server.
The Latin1_General_CI_AS_KS_WS option translates to
Whether you create your content
databases from within SharePoint or let your SQL DBA create them, there
are certain settings that you should check to make sure that your
SharePoint databases are running as optimally as possible on your SQL
Server. You should review your SharePoint SQL Server instance and each
of your SharePoint content databases to ensure they meet the following
criteria.
Change the default path of
your data and log files after you install SQL Server and before you
start creating databases so that SharePoint will have fault tolerance
and high availability. Check your available memory and determine what
other applications, besides the operating system, will require physical
memory, then calculate and set your minimum and maximum memory settings
to avoid performance degradation of SharePoint and other applications
running on that server.
Remember, the
Autogrowth settings are a contingency for unexpected growth and should
not be used as a day-to-day action. To avoid using Autogrowth except
when absolutely necessary, analyze the amount of information you expect
to be in your SharePoint databases and set their initial size to hold
the anticipated amount of content.
Use the full recovery model to provide the opportunity to recover
information in the event of a hardware failure, as discussed in the
next section.
5. Tempdb Database Settings
SharePoint performance can also be improved with a properly configured Tempdb
database. The Tempdb database is the temporary work storage area that
is used when sorting content, and its location and configuration can
impact SQL Server performance—and ultimately SharePoint’s performance.
Similar to the Model database, the location, Initial Size, and
Autogrowth settings for the Tempdb database can affect your overall
SharePoint performance.
Make modifications
to the Tempdb database similar to those suggested for the Model
database. The Tempdb database is cleared out each time you stop and
start your SQL Server instance, so if it isn’t properly configured, it
will experience the same growth issues as the Model database, causing
performance issues for your users.
The following list contains recommendations for optimizing your Tempdb database in your production environment.
Place the Tempdb database on the fastest I/O subsystem available. Use disk striping if there are many directly attached disks.
Pre-allocate
space for your Tempdb files by setting the Initial File size to a
larger value so it can accommodate the typical workload in your
environment.
Create multiple data files to maximize disk bandwidth. This reduces Tempdb storage contention and yields better scalability.
Allow your Tempdb files to grow automatically as needed.
Table 1. Suggested Tempdb File Growth Increments
| TEMPDB FILE SIZE | FILE GROWTH INCREMENTAL VALUE |
|---|
| 1–100 MB | 10 MB |
| 100–200 MB | 20 MB |
| 200 MB or more | 10% |
Put the Tempdb database on disks other than those used by your content databases.
Set the recovery
model to simple, which is the default. This will automatically reclaim
transaction log space and keep the space requirements to a minimum.
If you can separate only one database from the rest, make it your Tempdb, because SharePoint performs reads and writes to it constantly. Your SharePoint installation can’t be faster than your Tempdb database. If possible, you should store the Tempdb database on a RAID 10 disk.
6. SharePoint Content Database Recovery Model
Every SharePoint
database that you create inherits the recovery model of the SQL Server
Model database for that instance of SQL Server. This recovery model
determines how your transaction log information is managed after the
information is written to your data files. There are three recovery
models to choose from.
Full Retains all data in transaction log after writing it to the data file (the default).
Bulk-Logged Retains entries made in transaction log when bulk transactions occur.
Simple Purges all transactions from transaction log after writing them to data file.
The recovery model
you choose for your SharePoint content databases will determine your
recoverability options, and they also can affect the performance of
SharePoint
6.1. What Is a Transaction Log?
A database transaction log
is instrumental in maintaining data integrity within that database. The
transaction log receives the following types of SQL Server actions,
called transactions.
New information added (Insert)
Existing information changed (Update)
Existing information deleted (Delete)
This means that if you add a
document to a library (insert), modify a task in a list (update), or
remove a document from a library (delete), the action is first written
to the content database transaction log. After a short period of time
(roughly 60 seconds), SQL Server runs a process called a checkpoint.
This checkpoint reads the inserts, updates, and deletes stored in the
transaction log and applies them to the data files for that database.
After writing them to the data files, the simple recovery model removes
those transactions from the transaction log file. Conversely, the full
recovery model retains those transactions in the transaction log file
The recovery model setting
will affect the recoverability of your data in the event of a disaster,
but the setting also can have a negative affect on performance. The
methods you use to back up your SharePoint content can have a major
impact on recoverability and performance of SharePoint. In the
following sections, you learn the advantages and disadvantages of using
the full and simple recovery models for your SharePoint databases.
3.6.2. Full Recovery Model
The full recovery model is the default recovery model—unless you change it on the Model database—for your SharePoint content
databases. This is the preferred recovery model because it means that
after the information is written to the data files, you retain the
information in the transaction log. This is helpful when you need to
recover your SharePoint content if your data files become corrupt or are lost because of a hard drive failure. However, it only works if you are storing your transaction log files on separate physical drives.
Most production environments use the full
recovery model because it provides you the opportunity to recover
changes made to your SharePoint content if you lose your data files.
You can recover lost data by performing a backup log action on the
transaction log and then restoring this backup after you restore your
SharePoint backups.
A disadvantage of using
the full recovery model is that when you perform a backup of your data
using SharePoint, the information in the transaction log files never
gets purged. The SQL Server transaction log files get purged only if
you perform an actual SQL Server BACKUP LOG command. After performing a backup of the transaction log from within Management Studio or using the BACKUP
LOG command, the information gets purged from the transaction log file,
which reduces the size of the transaction log back to its initial file
size. However, a backup performed from within SharePoint on one of its
databases that is set to full recovery never performs an actual backup
log action, which causes the transaction log files to grow to
significantly.
The changes in the
transaction log should be retained for recovery purposes until you
perform another full database backup. To prevent the transaction logs
from becoming too large, you can speak to your SQL Server DBA and ask
her to schedule a backup of your transaction logs to separate media
immediately after she performs a full database backup. Remember that
the full database backup contains all the information in the
transaction log, so you don’t need the transaction log information
anymore.
For instance, if you perform a
full database backup every Sunday night and you are using the full
recovery model, you can create a SQL Server job that runs after your
successful full database backup to then back up the associated
transaction log. However, you don’t need this transaction log backup.
You can simply delete the backup file that contains the transaction log
backup.
You can avoid the large transaction log files using these two steps.
Back up the transaction logs using the BACKUP LOG command or from within Management Studio.
Delete the backup file created in step 1.
The following commands can be used to create a SQL server job that you can schedule to perform a full backup, a transaction log backup, and then delete the transaction log backup.
BACKUP DATABASE contosoportal TO DISK = 'C:\sqlbackups\fullbackup.bak'
BACKUP LOG contosoportal TO DISK = 'C:\sqlbackups\logbackup.bak'
DELETE 'C:\sqlbackups\logbackup.bak'
You perform the
transaction log backup to purge the old transactions and prevent the
transaction log files from becoming too large. Use the following steps
to take advantage of the full recovery model while preventing the transaction log files from becoming too large.
Periodically perform a full database backup of your SharePoint database.
Immediately after a successful full database backup, back up the transaction log.
Delete the file created when you backed up the transaction log.
Optionally, schedule periodic backups of your transaction logs.
Using these steps will allow you to use the full recovery
model that will be beneficial in a disaster recover scenario, at the
same time preventing your SQL Server transaction logs from becoming too
large.
6.3. Simple Recovery Model
The simple
recovery model is used primarily in development environments, because
the information is temporary or is being used for testing. When you use
this recovery model, the information stored in the transaction log is
purged after it is written to the data file.
The disadvantage of the simple
recovery model is that it doesn’t allow you to back up the transaction
log. In the event that you have corrupt data files or you lose data
during a hardware failure, you won’t be able to recover the changes
made since your last full or differential backup.
The advantage of the simple
recovery model is that it never grows too large, because the
transactions are purged as soon as they are successfully written to the
data files. This prevents the need to create a job to back up the
transaction log and delete the backup file created during the backup of
the transaction log.
Although you might prefer using the simple recovery model in your development environment, it is a best practice to use the full
recovery model in your production environments. This provides you the
opportunity to recover all changes regardless of when the last backup
was performed.
Discuss your options with
your DBA to decide which recovery model is best for your specific
situation and make sure that you have a proper recovery plan in place
for your SharePoint implementation.
7. Verifying Data Integrity Using DBCC CHECKDB
The Transact-SQL programming language provides a number of Database
Console Command (DBCC) statements that act as commands you can run to
verify the integrity of your SQL Server. These DBCC statements can be
grouped into the following categories.
Maintenance Maintenance tasks on databases, indexes, or filegroups
Miscellaneous Enable trace flags, remove DLLs from memory
Informational Gather and display various types of information
Validation Validate operations on databases, tables, and allocation of pages
The DBCC statements are
designed to accept input parameters and return values and information.
Some DBCC statements run on internal read-only databases to prevent
blocking and concurrency problems while they execute. This is
accomplished by creating internal snapshots of the database before
running the command and dropping the internal database immediately
after the command completes.
You should run the DBCC
CHECKDB statement with REPAIR_REBUILD regularly on your SQL Server
databases to verify the logical and physical integrity of all the
objects in the specified database and perform some minor repairs to
your database that will not result in any data loss. Here are a few of
the operations the DBCC CHECKDB statement performs.
Runs DBCC CHECKALLOC to check the consistency of the disk space allocation structures
Runs DBCC CHECKTABLE to check the integrity of all pages on every table and view
Validates the contents of the indexed views in the database
